User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

On Twitter, playing a video shows a volume icon that can only mute or unmute the video. The slider used for controlling the actual volume is missing. Problem persists even after following all steps in the troubleshooting guide at: https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems

Actual results:

The volume button only mutes and unmutes the video. No slider used for controlling video volume was displayed.

Expected results:

On hover over the volume button, display a volume slider to control video volume. This is the expected behavior by default, and works on other browsers such as Edge, Chrome etc.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Noticed a weird occurrence. When 2 mice are connected at the same time, the volume control miraculously appears upon page refresh! I have tested this with multiple mice and tried to mix and match them to eliminate any sort of driver error or some such, but it is in fact fully reproducable.

When returned to only 1 mouse, the volume button disappears again on page refresh. Very perplexing behavior indeed. Seeing as this only occurs on Firefox, and using just 1 mouse is fine on other browsers, I suspect it has something to do with how Firefox detects input devices?

This issue also does not occur on the ESR version of Firefox. All other versions, be it Release, Beta, Developer, Nightly all have the same issue.

Sounds like this might be a regression from ESR? A regression range would be helpful. We have a tool that helps find these, you can try it out here https://mozilla.github.io/mozregression/.

Sorry, I messed that up. I have attached the logs and final build info instead. I hope this helps.

Looking further at the specific revision on: https://hg.mozilla.org/mozilla-central/rev/fb3194cfa194

I cant really read the code but I noticed it mentioned dom_w3c_pointer_events_scroll_by_pen_enabled

I went into about:config and switched this variable from the default true to false, and after restarting firefox, the volume slider appears even when using 1 mouse!

I am pretty convinced this commit has something to do with this issue.

Thanks for the diagnosis outrageouspeach!

(In reply to outrageouspeach from comment #2)

Noticed a weird occurrence. When 2 mice are connected at the same time, the volume control miraculously appears upon page refresh! I have tested this with multiple mice and tried to mix and match them to eliminate any sort of driver error or some such, but it is in fact fully reproducable.

That code path is only expected to run on a pen input, as WM_POINTER does not fire from a mouse by default. I guess the mouse is somehow being treated in a special way by Windows?

Some questions:

• What specific mice are you using?
• What does "Settings app -> System -> About -> Pen and touch" say?
• When you copypaste data:text/html,<script>onpointermove = ev => alert(ev.pointerType)</script> on the address bar and move the cursor using your affected mouse, what does the popup say?
  • And what does it say on Chrome?
• Is there any situation when you can reproduce this with only one mouse?
• Does any specific configuration in your mouse software come to your mind?

(In reply to Kagami [:saschanaz] from comment #10)

(In reply to outrageouspeach from comment #2)

Noticed a weird occurrence. When 2 mice are connected at the same time, the volume control miraculously appears upon page refresh! I have tested this with multiple mice and tried to mix and match them to eliminate any sort of driver error or some such, but it is in fact fully reproducable.

That code path is only expected to run on a pen input, as WM_POINTER does not fire from a mouse by default. I guess the mouse is somehow being treated in a special way by Windows?

Some questions:

• What specific mice are you using?
• What does "Settings app -> System -> About -> Pen and touch" say?
• When you copypaste data:text/html,<script>onpointermove = ev => alert(ev.pointerType)</script> on the address bar and move the cursor using your affected mouse, what does the popup say?
  • And what does it say on Chrome?
• Is there any situation when you can reproduce this with only one mouse?
• Does any specific configuration in your mouse software come to your mind?

Hi, I changed the dom_w3c_pointer_events_scroll_by_pen_enabled variable I mentioned back to true for the following tests and answers:

• What specific mice are you using? :
  I have tested a Logitech G502 Hero, which is running Logitech G Hub as the control software, a standalone Razer Deathadder Chroma with no drivers installed, and an unbranded USB mouse.

• What does "Settings app -> System -> About -> Pen and touch" say? :
  Under the Device specifications tab -> Pen and touch it says Pen support

• When you copypaste data:text/html,<script>onpointermove = ev => alert(ev.pointerType)</script> on the address bar and move the cursor using your affected mouse, what does the popup say? :
  Testing with all 3 mice, the popup says mouse

• And what does it say on Chrome? :
  In chrome, testing with all 3 mice, the popup still says mouse

• Is there any situation when you can reproduce this with only one mouse? :
  Nope. Using a single mouse from any of the 3, the volume slider fails to appear in Firefox. When connecting any 2 of the 3 mice, the volume slider appears again. This behavior does not happen in Chrome. Using a single mouse in chrome, the volume slider appears as normal.

• Does any specific configuration in your mouse software come to your mind?:
  In Logitech G Hub, the settings for the G502 mouse changes the DPI and Report Rate, as well as the RGB values for the LED on the mouse. I assume the LED does not matter, so I have tried modifying both the DPI and Report Rates. No changes were observed, the volume slider still does not appear after modifying the values.

Do let me know if you need any further information!

:calixte, since you are the author of the regressor, bug 1811303, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

(In reply to outrageouspeach from comment #11)

• What does "Settings app -> System -> About -> Pen and touch" say? :
  Under the Device specifications tab -> Pen and touch it says Pen support

Do you have a pen on your device, btw?

(In reply to Kagami [:saschanaz] from comment #13)

(In reply to outrageouspeach from comment #11)

• What does "Settings app -> System -> About -> Pen and touch" say? :
  Under the Device specifications tab -> Pen and touch it says Pen support

Do you have a pen on your device, btw?

I have a pen tablet, One by Wacom (Medium), as well as Wacom Center software used to control the tablet. However, I did not plug in the tablet during testing.

Any updates on this? Tried to revert the dom_w3c_pointer_events_scroll_by_pen_enabled variable back to true today and the bug still persists.

Hi reporter, sorry for long time no update! Unfortunately I have no news here, what I understand is:

1. There's something in your system that makes the OS believe your computer has a pen.
2. But how is it affecting the page? It's currently unclear as per comment #11 it's still mouse.
3. Even with all the above, Twitter should still show the volume control, as I see the control even with a real pen with every pref enabled. It's potentially thinking your mouse is a touch pointer, as it does not show the control when touched. But that's weird.

Hsin-Yi, is there any chance that you could assign someone to take a look, since I currently have no time to assign and to be fair I have no idea how to proceed. (It's currently in Widget but I think DOM Core generally covers input issues including pointer events. Correct me if I'm wrong!)

Edgar, can you please take a look at comment 16 and suggest the next step? Thank you.

Hi, is there any updates on this? Just tested again today and the bug still exists.

Does Windows Settings still say "Pen support" when you have none? I think that should be fixed first to reduce the possible culprits here.

Hi, I have some additional info on the "Pen support" situation.

I have discovered that when I uninstalled the Wacom Driver (Latest Version 6.4.4-3), upon reboot, Windows Settings will change from "Pen support" to "No pen or touch input is available for this display". When reinstalled, it will revert back to "Pen support". I can only assume that it's the Wacom Drivers that is causing this.

However, as the drivers are pretty much essential for my Wacom tablet to function properly, I can't just leave them uninstalled.

Can you maybe try it on your end and see if you can reproduce the same results?

Hmm, now that I have access to desktop and an (old) wacom tablet, I can try tomorrow. Thanks!

Hmm, so I got my CTL-460 and my desktop. But I still can't repro this issue:

1. I plug in my CTL-460 and install the driver. Settings say "Pen support".
2. Open Firefox and make sure all dom.w3c_pointer_events.* configs are in the default state (that is, dispatch_by_pointer_messages=true and scroll_by_pen.enabled=true)
3. Open https://twitter.com/mozilla/status/1711842858460655982 and play it
4. Hover over the volume icon either with the existing mouse or CTL-460 and see if the controller pops up (it does for both)

Do you see anything wrong or something can be added with the above steps?

Please disconnect the tablet while leaving the driver installed and try playing it again.

I found out that when the tablet is plugged in, the volume control works as expected, but when it is disconnected, the controls fail to appear.

I tried that too, but I could still find no issue 🤔

I tried three things:

1. Connect the tablet, open Firefox and interact with the pen, disconnect the tablet and see Twitter can show the control.
2. Open Firefox and then connect the tablet, and then test Twitter. (For this case I found that the visual selector does not open when selecting text, but that's a separate issue)
3. Disconnect the tablet, restart Firefox, and test Twitter.

No problem for my side for those cases.

(In reply to outrageouspeach from comment #23)

Please disconnect the tablet while leaving the driver installed and try playing it again.

I found out that when the tablet is plugged in, the volume control works as expected, but when it is disconnected, the controls fail to appear.

When you plug it out and open Settings, does it still say "Pen supported"? My system goes back to "No pen or touch support" in that case.

Yes, after unplugging the tablet and restarting the PC, Windows Settings still says "Pen Support"

That's weird, hmm. After you unplug the tablet, does Device Manager still show Wacom Tablet under Human Interface Devices? It goes away on my machine.

Yes, it disappears after disconnecting on my end too.

How is Windows saying you have a pen support when the driver is unloaded? 🤔

Which Windows version are you using btw? (The "OS build" in Settings➡️System➡️About)

I am currently on Windows 11 Insider Build (Beta) OS Build Number 22635.2915

Hmmmm. Maybe my CTL-460 is not the ideal device to test this as its latest driver is 5.3.5-3. Perhaps the behavior is changed at some point? Let me just install the driver without actual supported tablet...

Which Wacom tablet do you use, btw?

As mentioned before, I have a One by Wacom (Medium) Model No. CTL-672. The driver version is the latest: 6.4.4-3.

Thanks! And I now can confirm that installing the latest driver 6.4.4-3 breaks Windows pen support detection (says "Pen support" when nothing is working nor even connected), Firefox, and also my CTL-460. Firefox incorrectly reports navigator.maxTouchPoints === 1, but Chrome somehow resists and reports 0. I'll investigate more, but I think this is at least partially Wacom's fault...

Thanks for your help in testing. Good to know that this is reproducible and it's not just isolated to my end. If you need any more information or further testing, I am happy to assist.

Thank you for your continued report! I just found that installing the driver causes Windows to report NID_INTEGRATED_PEN which is so very wrong, this should only be reported for devices like Surfaces but not for external tablet devices.

Alright, finally figured out how this is broken.

1. As said in comment #36, the latest Wacom driver makes Windows believe there's a pen support regardless of actual device connection. With the scroll_by_pen flag on, this means Firefox also believes there's a touch device.
2. And then we have a mouse detection function, where we try to detect mouse but not a digitizer. Firefox thinks the device is not a mouse if it's the only input device in the system and the system reports touch/pen support: https://searchfox.org/mozilla-central/rev/9c509b8feb28c1e76ad41e65bf9fd87ef672b00f/widget/windows/WinUtils.cpp#1479-1486

This explains why connecting two mice or connecting the tablet fixes this issue: this is only problematic when there's only one device connected to the machine.

Trying to see whether the system-reported mouse is a REAL mouse causes problem in certain situation with Wacom driver. The driver makes the system believe it has a pen while it still reports that the input device count is 1. Our heuristic thus thinks that the single device is not a real mouse but something else, which then breaks web compatibility with Twitter.

That hack was added by bug 1493128, but the capability report behavior change is already reverted with bug 1813979. Keeping this hack thus has no point as of now. This patch follows the comment: "We shouldn't assume we know better."

https://hg.mozilla.org/mozilla-central/rev/f69fdcb8418b

The patch landed in nightly and beta is affected.
:saschanaz, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox122 to wontfix.

For more information, please visit BugBot documentation.

I'd like to let this ride the train to see whether there are any breakages.